home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13443 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 KB
  1. Path: news.csuohio.edu!usenet
  2. From: jabaker@grail.cba.csuohio.edu (jason)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Pointers are hacks in c++ (portablity hackers etc)
  5. Date: 25 Mar 1996 12:14:38 -0500
  6. Organization: Dr Benway for Islam Inc.
  7. Sender: jason@jlbaker.async.csuohio.edu
  8. Message-ID: <vpwa1m6wu.fsf_-_@jlbaker.async.csuohio.edu>
  9. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <DoI5Ao.AyJ@assip.csasyd.oz>
  10.     <EJH.96Mar19163745@larry.gsfc.nasa.gov>
  11. NNTP-Posting-Host: jlbaker.async.csuohio.edu
  12. In-reply-to: ejh@larry.gsfc.nasa.gov's message of 19 Mar 1996 21:37:45 GMT
  13. X-Newsreader: Gnus v5.0.13
  14.  
  15. In article <EJH.96Mar19163745@larry.gsfc.nasa.gov> ejh@larry.gsfc.nasa.gov (Edward Hartnett) writes:
  16. > Hmmm. Most of what I would call hacked code is not code that violates
  17. > the standard by depending on undefined behaviour, but rather code that
  18. > does weird (but usually standard conforming) things with memory or
  19. > pointers.
  20.  
  21. What exactly constitutes pointer or memory weirdness?  I think that
  22. going through a list like:
  23.   list_cell **cell = &head;
  24.   while (*cell && (*cell)->member != value) cell = &cell->next;
  25. looks sort of weird, but is a well established practice.  XtOffset and
  26. stl's list cell management both do weird things, but encapsulate the
  27. gory details, and presumably work as intended.  Are these evil hacks?
  28.  
  29. I'm posting because I think I see a disturbing trend in c++.
  30. Programmers seem to have an unreasoning fear of pointers in general:
  31. An stl object lives in exactly one container, exactly one auto_ptr
  32. points at any object and reference counting mechanisms seem aimed at
  33. efficiently giving you a private object rather than sharing an object
  34. without leakage.  With these constructs, you can have only one
  35. reference to a new'ed object, something I find antithetical to the
  36. very notion of a pointer.
  37.  
  38. What is going on here?  One explanation is that c++ people do not like
  39. destructive modifications.  However, this does not seem to be the
  40. case.  Stl does not allow you to functional push new cells on the
  41. front of a list, not does it allow you to functionally push new
  42. associations on the front of a multimap -- common practice with lisp
  43. lists and a-lists respectively.
  44.  
  45. Belief in functional programming really does not explain the
  46. anti-pointer mood I think I see:  What could be more functional and
  47. safe than building a list of pointers into someone else's container
  48. and disposing of it before my function exits.  Yet Mumit's STL Newbie
  49. guide (http://www.xraylith.wisc.edu/~khan/software/stl) considers
  50. collections of pointers "a design flaw that leads to memory leaks and
  51. such lovely things."  
  52.  
  53. I think c++ programmers fear pointers precisely because C++ does
  54. nothing to solve the memory management problems of C.  Let's say I've
  55. built my list of pointers on the stack using the following macro:
  56.   #define Stack_new(_T, _ARGS) \
  57.   (void *_v = alloca(sizeof(_T)), new(_v) _T _ARGS)
  58. How should the list cells be destroyed:
  59.   if next is on the heap and has no other references,
  60.      then delete next.
  61.   if next is on the exiting stack frame and has other references,
  62.      then abort.
  63.   if next is on the stack and has no other references,
  64.      then destroy next.
  65.   if next has other references, or has static extent,
  66.      then do nothing.
  67. So, there are two questions.  How was next allocated -- this can be
  68. solved by ensuring that next always comes from the heap.  And, does
  69. anything else refer to next -- this can't be solved with a reference
  70. count, we are dealing with a linked list of arbitrary length, it can
  71. only be solved by ensuring that there are no other references.
  72.  
  73. It seems to me that garbage collection is the only solution here.
  74. But, c++ has avoided gc in the name of efficiency.  Instead, it gives us
  75. three partial solutions which ostensibly save CPU time and memory
  76. size:  Ensure that only one reference to each object exists by copying
  77. objects and propagating changes between the copies.  Keeping a running
  78. count of references to an object rather than periodically determine
  79. whether there are any references.  And, think through the memory
  80. management issues on a case by case basis, just like C.
  81.  
  82. Hmm, I read the Unix Hater's Manual a few months ago, and I am honestly
  83. not sure whether I am simply parroting their criticism of c++ or
  84. actually having thoughts of my own.  Anyway, if someone can straighten
  85. me out about multiple references to objects in c++, or if I simply
  86. provoke a flame war I will be pleased.
  87.  
  88. Jason
  89.  
  90.